Literature has identified factors such as piracy, network externality, or concave cost of producing quality as key drivers of software versioning. However, software firms adopt versioning strategies that are often invariant across different market settings. To explain universal business practice of software versioning, we focus on ÒinconvenienceÓ or disutility that users experience when software has lower functionality than what they require to accomplish tasks. In our model, users are heterogeneous on marginal valuation for functionality and the required level of functionality such that those with higher valuation have a higher required level of functionality. Users do not derive any additional utility if the software has more functionality than what they require. We show that heterogeneous disutility from underprovisioning of functionality is a sufficient condition for optimality of versioning under fairly general conditions. We also show that, as high-type users' required level of functionality increases, the firm increases the functionality level of the high version. Yet surprisingly, the firm may decrease the functionality level of the low version if the proportion of high-type users is moderate. On the other hand, as the required level of functionality of low-type users increases, the firm may reduce the functionality level of the low version when the proportion of high-type users is high, though the functionality level of the high version remains the same. Counterintuitively, an increase in the high-type (low-type) users' required level of functionality negatively (positively) impacts high-type users' consumer surplus.
This paper extends prior research on the software vendors' optimal release time and patching strategy in the context of cloud computing and software as a service (SaaS). Traditionally, users are responsible for running on-premises software; by contrast, a vendor is responsible for running SaaS software, and the SaaS vendor incurs a larger proportion of defect-related costs than a vendor of on-premises software. We examine the effect of this difference on a vendor's choice of when to release software and the proportion of software defects to fix. Surprisingly, we find that, despite incurring a larger proportion of defect-related costs, it is optimal for the SaaS vendor to release software earlier and with more defects, and to patch a smaller proportion of defects, than the on-premises software vendor. Even though the SaaS vendor incurs higher defect-related costs, he obtains a larger profit than the traditional vendor. In addition, we find that for a vendor who uses the SaaS model, the optimal number of defects after patching may be lower than the socially efficient outcome. This occurs despite the fact that the number of defects after patching in the SaaS model is higher than in the traditional on-premises model.